Skip to content

fix(ui): restore the pre-rebrand gittensory_ legacy localStorage keys#7898

Closed
shin-core wants to merge 1 commit into
JSONbored:mainfrom
shin-core:fix/rebrand-legacy-localstorage-keys-7782-v2
Closed

fix(ui): restore the pre-rebrand gittensory_ legacy localStorage keys#7898
shin-core wants to merge 1 commit into
JSONbored:mainfrom
shin-core:fix/rebrand-legacy-localstorage-keys-7782-v2

Conversation

@shin-core

Copy link
Copy Markdown
Contributor

What & why

Closes #7782.

Commit 112bc4a83 (#5405) gave useLocalStorage a legacyKey param so a pre-rebrand gittensory_* localStorage value migrates forward to the new loopover_* key. 81e4ac34d (#5743, the full gittensoryloopover cutover) then did a blanket text substitution that also rewrote two string literals meant to keep the old prefix:

  • onboarding-preview-card.tsxLEGACY_DISMISS_KEY became identical to the current DISMISS_KEY.
  • notification-readiness-card.tsx — the notification opt-in legacy key became identical to its current key.

With key === legacyKey, useLocalStorage's fallback reads the same key it just missed under, so a maintainer who dismissed the onboarding card or opted into notifications before the rebrand silently loses that preference. Every other rebrand-migrated key (try-it.tsx's gittensory.session_token, etc.) survived intact.

The fix

Restore both legacy keys to their pre-rebrand gittensory_-prefixed literals, matching the still-correct try-it.tsx pattern. String-literal-only change — nothing rendered changes.

Because these two files now legitimately contain gittensory literals, scripts/branding-drift-baseline.json is regenerated (via npm run branding-drift:update) so the branding-drift check records them as intentional rather than flagging new drift — same generated-artifact discipline as ui:openapi / cf-typegen.

Tests

A regression test per component, extending the existing test file:

  • onboarding-preview-card: seeds gittensory_maintainer_onboarding_preview_dismissed and asserts the card stays hidden, the demo API call is skipped, and the value is written forward to the current key.
  • notification-readiness-card: seeds gittensory_notification_opt_in and asserts the pill shows "opt-in enabled" and the value is migrated to the current key.

Verified bug-catching: reverting either key to the corrupted loopover_ value fails its regression test.

Validation

  • apps/loopover-ui: vitest run (both files, 11 tests) pass; tsc --noEmit exit 0; eslint clean; Prettier clean.
  • npm run branding-drift:check — ok (41 files match the regenerated baseline).
  • Per the issue, apps/loopover-ui is not under the src/** 99% patch gate; the regression tests are the coverage deliverable. Branched off current main, mergeable-clean.

JSONbored#5743's blanket gittensory->loopover rename overwrote two localStorage legacy-key
string literals that were supposed to keep the OLD prefix, so useLocalStorage's
migration fallback read the same key it had just missed under -- silently dropping
a pre-rebrand preference. Restore LEGACY_DISMISS_KEY in onboarding-preview-card and
the notification opt-in legacy key in notification-readiness-card to their
gittensory_-prefixed values (matching the still-correct try-it.tsx pattern), so a
maintainer's pre-rebrand onboarding dismissal / notification opt-in migrates
forward instead of appearing lost. Regenerate scripts/branding-drift-baseline.json
so the two intentionally-restored gittensory_ literals are recorded, not flagged as
drift. Adds a regression test per component that seeds the legacy key and asserts
the value is read forward to the current key.
@shin-core
shin-core requested a review from JSONbored as a code owner July 21, 2026 16:34
@superagent-security superagent-security Bot added the contributor:flagged Contributor flagged for review by trust analysis. label Jul 21, 2026
@superagent-security

Copy link
Copy Markdown
Contributor

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@codecov

codecov Bot commented Jul 21, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.40%. Comparing base (2364ad4) to head (3eb6032).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #7898   +/-   ##
=======================================
  Coverage   91.40%   91.40%           
=======================================
  Files         730      730           
  Lines       74789    74789           
  Branches    22822    22822           
=======================================
  Hits        68358    68358           
  Misses       5389     5389           
  Partials     1042     1042           
Flag Coverage Δ
shard-1 57.98% <ø> (ø)
shard-2 51.23% <ø> (ø)
shard-3 51.15% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

@loopover-orb loopover-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 21, 2026
@loopover-orb

loopover-orb Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Warning

⏸️ LoopOver review result - manual review recommended

Review updated: 2026-07-21 16:51:10 UTC

5 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This restores two `gittensory_`-prefixed legacy localStorage key literals that a prior blanket rebrand rename had accidentally collapsed to equal their current-key counterparts, breaking `useLocalStorage`'s fallback-read migration path. The fix is a precise, minimal string-literal correction matching the still-correct `try-it.tsx` pattern, backed by a regression test per component that seeds the legacy key and asserts both UI behavior and forward-migration to the new key. The branding-drift baseline update is properly scoped to just the two touched files, consistent with the stated generated-artifact discipline.

Nits — 4 non-blocking
  • The failed 'Contributor trust' check is unexplained in this context (no detail provided) and the branch is 2 commits behind default — likely unrelated to this diff's content, but worth confirming before merge.
  • onboarding-preview-card.test.tsx's new test doesn't clear localStorage after itself (unlike notification-readiness-card.test.tsx's test), though beforeEach already clears it so this is low-impact.
  • Consider adding a shared test helper/fixture for 'seed legacy key, assert migration + forward-write' since both test files now duplicate nearly identical migration-assertion logic.
  • Double-check no other components besides these two and try-it.tsx have a similarly corrupted legacyKey literal from the same feat(build)!: Phase 5 - full-cutover rename all gittensory-* directories to loopover-* #5743 rename, since this PR fixes exactly two instances without evidence of a full audit.
Flagged checks (non-blocking)
  • Contributor trust — Contributor flagged for review

Decision drivers

  • ✅ Code review — No blockers (1 reviewer)
  • ✅ Gate result — Passing (No configured blocker found.)
Context & advisory signals — never blocks the verdict
Signal Result Evidence
Linked issue ✅ Linked #7782
Related work ✅ No active overlap found No same-issue or scoped active PR overlap found.
Change scope ✅ 20/20 Low review scope from cached public metadata (1 linked issue).
Validation posture ✅ 25/25 PR body includes validation/test evidence.
Contributor workload ✅ 10/10 Author activity: 90 registered-repo PR(s), 50 merged, 0 issue(s).
Contributor context ✅ Confirmed Gittensor contributor shin-core; Gittensor profile; 90 PR(s), 0 issue(s).
Improvement ✅ Minor risk: clean · value: minor · LLM: moderate
Linked issue satisfaction

Addressed
Both legacy keys are restored to their gittensory_-prefixed literals distinct from the current keys, matching the try-it.tsx pattern, and each component gets a regression test seeding the legacy key and asserting correct migration.

Review context
  • Author: shin-core
  • Role context: outside_contributor
  • Public audience mode: oss maintainer
  • Lane context: Repository is configured for direct PR review.
  • Public profile languages: TypeScript, JavaScript, Solidity, Dart, Python, CSS, PHP, Rust
  • Official Gittensor activity: 90 PR(s), 0 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Keep the PR focused and include validation evidence before maintainer review.
Signal definitions
  • Related work = same linked issue, overlapping active PRs, or title/path similarity.
  • Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
  • Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
  • Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
  • Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.
🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @loopover ask &lt;question&gt; answers contribution-quality Q&A with source citations and freshness.
  • @loopover chat &lt;question&gt; answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview
Route Viewport Before (production) After (this PR's preview) Diff
/ desktop before /
before /
after /
after /
/ mobile before / (mobile)
before / (mobile)
after / (mobile)
after / (mobile)

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview
Route Before (production) After (this PR's preview)
/ before / (scroll)
before / (scroll)
after / (scroll)
after / (scroll)

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed


💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

  • Re-run LoopOver review

@loopover-orb

loopover-orb Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

This pull request changes UI/visual code but its screenshot evidence is incomplete. Every required viewport × theme combination needs its own before/after image pair in a labeled table row (e.g. "Desktop · Light | before | after"). Still missing: Desktop · Dark, Tablet · Dark, Mobile · Dark.

Please resubmit with the remaining rows filled in.

See https://github.com/JSONbored/loopover/blob/main/.claude/skills/contributing-to-loopover/SKILL.md for the exact format and examples. This is an automated maintenance action.

@loopover-orb loopover-orb Bot closed this Jul 21, 2026
@shin-core

Copy link
Copy Markdown
Contributor Author

Summary

.github/superagent.yml lists shin-core in contributorTrust.trustedAuthors (added in 5d10bb5b, alongside dhgoal and andriypolanski), which per the file's own comment should exempt these accounts from contributor-trust scoring entirely. But on shin-core's PRs the Contributor trust check still reports Score: 10/100 · Verdict: dangerous and routes the PR to manual review, while a co-listed account (andriypolanski) merges cleanly. It looks like the live Superagent app config isn't reflecting the trustedAuthors entry for this account.

Evidence

Current main .github/superagent.yml:

contributorTrust:
  enabled: true
  blockBelowScore: 30
  trustedAuthors: [dhgoal, shin-core, andriypolanski]

Recent shin-core PRs — all with a clean Superagent Security Scan ("No suspicious PR changes were detected") — still show the trust check at 10/100 dangerous:

Meanwhile andriypolanski (same trustedAuthors list) auto-merges (e.g. #7991, #7989, #7977 on 2026-07-22).

Impact

The trust flag routes every shin-core PR to manual review instead of auto-merge, so correct, gate-approved work waits in the queue and is sometimes closed there while unflagged contributors merge the same issues. The Superagent config comment itself notes this scorer trips "on volume/velocity alone, not on any real signal" — which is exactly why the trustedAuthors exemption exists.

Ask

Could the Superagent app's live config be re-synced / the trustedAuthors exemption confirmed for shin-core (as it evidently is for andriypolanski)? If there's a threshold or a per-account propagation step the exemption needs, happy to wait — just flagging that the committed config and the live behavior currently disagree for this account.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contributor:flagged Contributor flagged for review by trust analysis. gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Two rebrand legacy-key fallbacks were silently destroyed by the gittensory->loopover blanket rename

1 participant